People today use multiple digital devices which are interconnected by various kinds of Local Area Network (LAN) and Personal Area Network (PAN) technologies. Examples of digital devices are home media servers. Many users want to access the home media servers from remote locations. Since those devices are usually connected to private LANs and in most cases, people wants to keep the contents private, there has to be a way to establish a private connection securely from the remote locations.
There are both proprietary and standardized solutions for accessing devices which are connected in a private network from a remote location.
An example is ETSI TISPAN (Draft ETSI TS 185 005 v3.2.2) which has specified IMS-based remote device access. It specifies a procedure to securely establish a tunnel to access devices in a private network from remote by Internet Protocol Multimedia Subsystem (IMS) signaling. As a result of the IMS signaling, port mapping is created by Universal Plug and Play (UPnP) or a Transmission Control Protocol (TCP) tunnel is setup.
Web technologies have evolved dramatically in last several years. With the help of technology evolution, web browsers are becoming an important software platform, rather than just one of applications.
It has an important advantage to develop an application so that it works on web browsers, that is, the application will become hardware or operating system independent. For example, once we write an application which works on a modern web browser, it works on computers with any of major operating systems. Moreover, it even works on mobile and embedded devices as far as the platform has a modern web browser.
However, the issue of addressing web clients for sending messages to them is lacking in the current web technologies. Since HyperText Transfer Protocol (HTTP) was developed on server-client model, only servers have addresses, i.e. HTTP Uniform Resource Locators (URLs), and clients cannot be addressed from a server until they access the server. WARP (Ericsson Labs, “Web Connectivity”, https://labs.ericsson.com/apis/web-connectivity/connectivity/ is a technology developed by Ericsson Research which addresses the issue and make web clients addressable. WARP clients are authenticated by WARP server and assigned an address. Once an address is assigned, any clients and servers on the WARP domain can send message to each other. WARP also provides web technology with session management, authentication and message integrity. A Web Device Connectivity (WDC) API is developed by using WARP. The API enables to blend connected devices in web pages and to use them seamlessly as if those devices are part of web resources. For example, the user can drag and drop a Youtube video link to an icon which represents a DLNA enabled TV to instruct the TV to play it out.
FIG. 1 shows a high-level Web Device Connectivity (WDC) architecture. A private network 100 is established and connected to the Internet 142 and Warp network 140 via an IP router 130. The private network 100 comprises a plurality of devices 110 such as DLNA devices which are connected to a Personal Network gateway (PN Gw) 120. As can be seen in FIG. 1, Warp is used as an underlying messaging system between a web application, the personal network (PN) gateway 120, and PN Application Server (PNAS) 180.
The web application on a device 150 also referred to as client is exemplified by an HTML/CSS/Javascript application running on a web browser which is loaded from arbitrary web sites 170. One example of a Web application is a Social Networking Service (SNS) application which is loaded from a SNS site such as Facebook.
The PNAS is an in-cloud server which consists of the following sub components:
A context manager (CM) 192, which is a database to maintain context information of devices or PN context. It also notifies other enablers, such as the PN gateway 120, a Service Broker 190 and an identity, authentication and authorization (ID/AA) unit 194 of changes in the contexts. The PN context and context addressing are so designed to make good use of the way of accessing resources in Warp.
The service broker (SB) 190 receives a request via a WDC API 145 to control devices and dispatches it to the PN gateway after policy enforcement.
The ID/AA unit 194 is used when WDC is used in conjunction with SNS. It stores identity mapping between SNS identity, Warp user identity, and PN ID of each user. It maintains the policies created by the end users and social relation in SNS is also taken into account when authorizing device access requests.
The PN gateway 120 is a service gateway attached to each user's LAN and has the following three functions: discovery of devices in the LAN, publishing the information regarding discovered devices to the context manager (CM) and controlling devices according to requests from the service broker (SB).
The following describes a scenario in the WDC architecture.    1. When the user starts a web application on a web browser, the user loads his/her context information including available device lists from CM at PNAS.    2. When the user performs an operation which triggers a device to perform an action, e.g. playing back a media content, an action request is issued from the application to the SB at the PNAS.    3. The SB looks up a PN gateway which is responsible for the received action and dispatches it.    4. The PN gateway executes the action on the specified device.
Another issue in remote access is NAT traversal. Most private networks are behind a Network Address Translation (NAT) and/or a firewall and hence hosts inside such a private network are not directly reachable from the external network.
Many techniques exist, but no single method works in every situation since the NAT behavior is not standardized.
Although there are various solutions for accessing devices in private networks from remote locations, they have difficulty to offer services in which the device access is blended as part of web experience.
In order to offer services with the above mentioned web experience, there are three major issues that need to be solved. Firstly, enabling exchange of signaling messages between a web browser which works as a remote access client and target devices and secondly authentication and authorization of signaling messages between web browsers and target devices. As the third issue, media transport sessions have to be established between the media server and the client.
Since WARP provides an address to each WARP client and if there is a PN gateway component which intermediates communication between devices and web browsers by bridging device specific protocols and WARP, respectively, the first issue is solved.
The second issue is also solved by WARP because each WARP client is authenticated by WARP server and message integrity is assured. So by having a simple access list at the gateway component, authentication and authorization are enabled.
However, messages over WARP always traverse the WARP server and thus it is not appropriate to use WARP for transporting the actual media. For example, in case of accessing a video content stored in Digital Living Network Alliance Network (DLNA) Digital Media Servers (DMS) at home, all the video stream needs to be handled by the WARP server. It will generate unnecessary load on the WARP server and the network. In case the network distance between the WARP server and a media server and/or a client is long, it does not only increase latency between the server and client, but also increase load on the path and possibility of QoS degradation.